Some client devices may have network access, but their network access may be limited to a set of application services. In one example, a client device's network access may be sponsored by a particular application service provider. The client device may be limited to application services run by the application service provider on its server. In another example, a client device with network access may be part of a contract that allows for special charging or handling of data (e.g., bit rate of quality of service) associated with a given application service. For example, a client device may have a cellular subscription through a cellular provider and that cellular provider may wish to impose one or more restrictions on the client device. In one example, a corporation that is today known as a provider of social media, but not known as a cellular provider, may play a role as a cellular provider. In this example, the client device may have a subscription with the corporation. As part of its subscription agreement, the client device may gain access to the Internet but may be restricted to use the social media site of the corporation to the exclusion of other social media sites. By way of another example, a client device may have a subscription with a provider of streaming media services. In this example, as part of an agreement, the client device may gain access to the Internet through various cellular providers but may be restricted by agreement (between the provider of streaming media services and the various cellular providers and/or the user of the client device) to use the site of the provider of media services for all streaming media services. By way of still another example, for certain access point names (APNs), only certain traffic may be allowed to be sent from a client device based on a policy or subscription limitation.
Policies may be instituted in connection with application services to ensure that a client device is not violating any agreements, is being provided access to a given application service, and/or is being provided with an agreed upon level of service. Such policies may be enforced against uplink (UL) packets sent from a client device toward, for example, a server on a packet data network (e.g., the Internet).
Today, policy enforcement for application services occurs at a gateway to a network. An example of such a gateway is a packet data network gateway (P-GW), which serves as a gateway between a network core (e.g., evolved packet core (EPC)) and a packet data network, such as the Internet. One problem exists in that enforcement of service access policies may require a P-GW to validate all UL packets sent from a client device. Moreover, each UL packet may need to be steered to its destination address via a particular bearer.
Validation of UL packets at the P-GW may be needed to ensure that a client device is only sending packets to an authorized application service. Validation may include verifying the destination address or the destination address and the port number of packets passing through the P-GW. Additionally, verifying the source address of each packet may be useful for anti-spoofing (e.g., by preventing packets from unauthorized client devices from fooling the system by appearing to come from an authorized client device). Packet steering may be needed to ensure that an agreed upon quality of service (QoS) is achieved.
Current practices incur substantial overhead and add forwarding latency due to processing delay. The current practice is typically realized using packet inspection (e.g., deep packet inspection, shallow packet inspection) and traffic flow template (TFT) and service data flow (SDF) templates. The P-GW confirms that the UL packets conform to a TFT/SDF template defined for the service(s) by inspecting the headers of each packet.
Fine-grain policy control (e.g., per application) is difficult because additional policy control would incur additional overhead and processing delay because a packet would need to be tested against additional filtering rules realized by TFT/SDF templates. Furthermore, use of TFT/SDF templates is not scalable for sponsored connectivity. An increase in the number of sponsors of different services (perhaps thousands of services in the years to come) would mean an increase in the time needed to filter packets through a correspondingly increased number of TFT/SDF templates. This, again, would incur additional overhead and processing delay.
What is required is an alternative to supplement and/or enhance packet inspection.